Overview：新手上路，請多包容

作為一個軟體小白，網路上的資訊琳瑯滿目，最容易碰到的問題莫過於沒有頭緒、不知道從何下手的棘手狀況。有了 AI 的協助以後，不應該只專注於過去所強調的程式語法或語法細節，取而代之的是優先學習系統設計觀念與資料架構思維。

舉例來說，如果今天想要上架一個管理代購的 app，可能最先碰到的不是寫不出程式碼，而是程式碼產生之後，難以跟實際的情況結合——原因很簡單：實際的複雜程度往往更高。反過來說，沒有優先學習系統架構，仍然可以做出一個代購 app，但如果有一條能大幅降低後續返工風險的路可以走，以機會成本的角度來說，何樂而不為？

Methods：Top-down 學習法

Top-down 比起傳統的 Bottom-up 學習法，是一種以宏觀走向微觀的快速學習方法。這 30 天的內容，我會搭配 Top-down 學習法，用淺顯易懂又不失專業的筆記方式，帶大家認識系統的設計與架構。

Takeaways

透過這 30 天的學習筆記，我會分成 5 大階段：從問題分析與邊界（Scope & Context）、資訊架構與資料流（Data Flow & State），再到模組化與重構原則（Modularity & SOLID）、工程防護與品質保證（Quality & Ops），最後至系統演進與頂層反思（Scalability & Retrospective），一路帶大家認識 System Level、Data Level、Module Level、Execution Level、Evolution Level，熟悉系統架構的脈絡。

一、系統邊界與約束條件：所有系統或專案都受鐵三角（Iron Triangle / Triple Constraint）的約束

核心原理：三重限制——範疇、時間、成本三個元素互相牽制，定義專案邊界與基準。

運行法則：三者具互相依賴性，任一項發生變動或取捨，都會直接影響交付品質。

1. 如果增加範疇（想做更多功能／想有更多產出），就必須增加時間（延後交付期限）或增加成本（加派人手或資金）。
2. 如果壓縮時間（提前交付），就必須削減範疇（削減功能）或提高成本。
3. 範疇、時間、成本三者達成平衡的結果，會決定最終交付的品質。

二、範疇 vs. 約束

範疇：定義系統的邊界

定義：專案需要完成的所有工作內容及最終交付的具體成果（Deliverables）

例如：系統要支援哪些功能、資料模型涵蓋哪些欄位、介面支援哪些操作方式

核心工具：

1. In Scope / Out of Scope：明確界定「做什麼」與「不做什麼」
2. WBS（Work Breakdown Structure）工作分解結構：把大功能層層拆解成可執行的小任務，提升時程與工時估算的精準度
3. 範疇蔓延管控（Scope Creep Control）：防止未經審核的需求隨意加入，導致時程拖延或預算赤字

約束：定義系統的限制條件

定義：專案執行中所面臨的不可變或有限的邊界條件

核心工具：

1. Time｜時間：交付截止日、各階段里程碑、開發時程
2. Cost/Resources｜成本與資源：硬體預算、伺服器開銷、人力配置上限
3. Technical Constraints｜技術約束：限定執行環境、通訊協議、效能門檻
4. Law/Standards｜法規標準：資安規範、個資保護法規或產業標準

三、實例應用

情境 1：小多團隊想要做一個代購 app，被要求在 2 個月內完成上架。
應用：為了如期上線，團隊必須縮減非核心功能的開發，專注於核心功能的驗證。

情境 2：小多團隊被要求 app 的上線時程縮短至 1 個月。
應用：若想要維持既有的產出品質，公司必須額外聘請人力以支援此專案。

情境 3：小多團隊答應客戶「順便增加一個按鈕」，回去團隊裡的工程師發現這個按鈕會牽涉底層資料庫架構重構，導致專案時程延誤。
應用：典型範疇蔓延的案例。應學會釐清變更控制的流程，遇到額外的需求時主動回報，透過正式的變更流程評估影響，避免客戶誤以為追加需求不需要額外成本。

情境 4：小多團隊需要評估代購 app 裡會員系統功能的上線時程。
應用：可利用 WBS，將大型功能拆成登入、註冊、忘記密碼等小型任務，提升時程安排和工時估算的精準度。

四、結論

近似於「資源有限、慾望無窮」這個經濟學基本假設，軟體工程架構裡的範疇、時間、成本三者相互制衡。開發過程時常會有這個也想做、那個也可行的想法，建立「範疇管控」的觀念，才能杜絕專案永遠無法完工的困境。

現實開發的複雜度往往比介面呈現本身高出不少，缺少系統架構與系統分析的觀念，會讓後續想擴充功能時，發生全部從頭重新來過的結果，這也凸顯條件約束的重要性。清楚這些系統架構，才能確保每一行程式碼都具備擴展性和可維護性，並讓開發週期更具效率。